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ABSTRACT 

This  paper  addresses  the  use  of  Resource  ReSerVation 
Protocol-Aggregate  (RSVP-AGG)  at  the  tactical  edge  of 
the  Air  Force ’s  Airborne  Network  (AN).  Since  the  AN  tac¬ 
tical  edge  can  have  different  types  of  stub-networks  ac¬ 
cessing  the  AN  (i.e.,  non-IP  based  legacy  networks  like 
Link  16,  DiffServ  based  networks  and  IntServ  based  net¬ 
works),  RSVP-AGG  offers  a  common  access  approach  re¬ 
gardless  of  the  differences  in  the  networks  using  the  AN. 
The  paper  presents  a  novel  RSVP-AGG  approach  that  has 
the  advantage  of  decreasing  the  burden  on  the  AN  core 
links  with  limited  bandwidth  by  reducing  RSVP  control 
traffic  over  the  encrypted  core.  Also,  the  paper  shows  that 
RSVP-AGG  (being  a  single  reservation  instead  of  multiple 
reservations)  could  be  more  resilient  to  link  errors.  More¬ 
over,  using  RSVP-AGG  over  the  AN  core  could  open  the 
door  to  consider  the  advantages  of  statistical  multiplexing. 

I,  INTRODUCTION 

The  vision  of  the  Air  Force’s  Airborne  Network  (AN)  is  to 
interconnect  tactical  edge  networks  and  offer  reach-back 
capabilities  for  Warfighters.  Future  capability  demands  on 
the  AN  and  its  unique  aspects  create  many  challenges. 
This  paper  addresses  the  use  of  Resource  ReSerVation 
Protocol-Aggregate  (RSVP-AGG)  between  the  enclaves  of 
an  AN.  Since  the  edge  enclaves  can  have  different  types 
and  categories  of  traffic  [i.e.,  non-Internet  Protocol  (IP) 
based  legacy  networks  like  Link  16,  Differentiated  Ser- 
viees  (DiffServ)  based  networks  such  as  Joint  Tactical 
Radio  System  (JTRS),  and  Integrated  Services  (IntServ) 
based  networks],  RSVP-AGG  offers  a  common  access 
approach  regardless  of  the  differences  in  network  enclaves 
using  the  AN.  The  paper  also  studies  the  effects  of  link 
reliability  over  RSVP  and  RSVP-AGG  protocols,  as  well 
as  the  amount  of  savings  of  bandwidth  (BW)  for  RSVP 
control  signaling  gained  from  using  RSVP-AGG.  Finally, 
RSVP-AGG  over  the  AN  core  can  lead  to  exploiting  statis¬ 
tical  multiplexing  where  multiple  RSVP  tunnels  are  re¬ 
placed  with  a  single  tunnel.  This  is  associated  with  an  ad¬ 


mission  control  mechanism  that  considers  tactical  net¬ 
works’  need  for  Multi-Level  Precedence  and  Preemption 
(MLPP)  where  the  higher  precedence  traffic  is  assured 
Quality  of  Service  (QoS)  at  the  expense  of  lower  prece¬ 
dence  traffic. 

II.  CHARACTERISTICS  OF  THE  AN 

Some  of  the  assumptions  for  the  AN  that  are  different  from 
those  of  commercial  networks  are  as  follows: 

Bandwidth  is  Limited 

Since  the  AN  uses  wireless  links,  spectrum  availability  can 
limit  BW  for  the  AN  links.  This  is  a  major  difference  from 
wired  networks,  where  fiber  optic  links  typically  offer  a 
very  large  BW  for  applications  requesting  reservations, 
and  most  of  the  time,  have  a  guaranteed,  or  even  over¬ 
provisioned  BW  with  virtually  no  error  rate.  Limited  BW 
can  mean  that  it  is  likely  that  a  reservation  will  be  denied. 
Hence,  some  intelligence  is  needed  at  the  ingress  and 
egress  points  to  ensure  that  solving  contention  problems 
accommodates  the  mission’s  needs. 

Traffic  is  Heterogeneous 

While  traffic  in  commercial  networks  is  classified  accord¬ 
ing  to  delivery  requirements  with  classes  of  service  such  as 
interactive  voice,  interactive  video,  streaming  voice, 
streaming  video,  data,  ftp,  e-mail,  etc.,  traffic  in  tactical 
networks,  such  as  the  AN,  can  also  be  marked  according  to 
its  precedence.  Each  class  of  service  can  have  Routine, 
Priority,  Immediate,  Flash  or  Flash  Override  marking. 
Granting  or  denying  a  reservation  should  consider  prece¬ 
dence  requirements.  For  example,  we  should  ensure  that, 
we  will  not  admit  a  Routine  reservation,  while  we  are  de¬ 
nying  a  Priority  reservation  (for  the  same  resources).  We 
refer  to  this  traffic  prioritization  as  MLPP  based  IntServ. 
Another  aspect  of  heterogeneous  traffic  is  that  some  appli¬ 
cations  can  be  adaptable  while  some  others  are  not.  In  oth¬ 
er  words,  an  application  reserving  a  specific  BW  and  get¬ 
ting  a  denial,  can  request  a  smaller  BW,  and  if  admitted, 
operate  in  a  gracefully-degraded  mode.  It  is  anticipated 
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that  the  AN  would  have  a  mix  of  applieations,  ineluding 
those  that  ean  adapt  and  those  that  cannot. 

Security  is  a  Major  Concern 

The  AN  is  expeeted  to  have  a  eertain  level  of  network  se- 
eurity  ineluding  eneryption  [1],  Thus,  the  RSVP  approaeh 
[2]  should  eonsider  secure  reservation  teehniques  where 
BW  reservations  are  established  through  seeure  tunnels. 
With  this  assumption  eomes  the  need  for  the  AN  to  have 
either  pre-existing  tunnels  or  to  have  a  network  manager 
that  ean  plan  and  maintain  the  tunnels  (based  on  the  provi¬ 
sion).  We  eonsidered  RFC  4804  [3],  whieh  allows  the  use 
of  a  dynamie,  topology-aware  admission  eontrol  while 
redueing  reservation  signaling,  which  is  in-line  with  the 
AN’s  needs.  RFC  4804  also  allows  the  use  of  a  BW  bro¬ 
ker. 

Subnets  Accessing  the  AN  use  Different  Technologies 

The  AN  is  a  eore  network  with  different  stub  networks,  or 
enelaves,  eommunieating  over  it.  Flere  are  some  examples 
of  these  stub  networks: 

•  Wired  LAN  in  a  C2  location 

Access  to  the  AN  eould  be  from  a  C2  (Command  and 
Control)  post  with  a  standard  wired  Loeal  Area  Net¬ 
work  (LAN).  This  LAN  may  have  applieations  using 
standard  RSVP,  and  the  AN  aeeess  point  eould  offer 
RSVP-AGG  to  aggregate  all  these  reservations  under 
one  tunnel  [4]. 

•  Joint  Tactical  Radio  System  -  Airborne,  Maritime 
and  Fixed  (JTRS  AMF)  waveform 

In  this  case,  access  to  the  AN  is  coming  from  a  Diffe¬ 
rentiated  Services  Code  Point  (DSCP)  based  stub 
network  enclave.  The  AN  ingress  point  should  be  able 
to  convert  DiffServ  to  IntServ  through  techniques  such 
as  RSVP  Proxy. 

•  Legacy  waveform  (e.g.,  Link  16) 

A  legacy  waveform  may  not  be  using  IP  at  all,  with  a 
gateway  converting  its  traffic  into  IP  based  packets.  In 
this  case,  the  ingress  point  should  estimate  the  flow 
and  create  the  necessary  reservations  over  the  AN. 

Available  Bandwidth  may  change  due  to  Mobility 

The  RSVP-AGG  or  the  RSVP  Proxy  technique  at  the  AN 
ingress  point  needs  to  accommodate  the  changes  in  net¬ 
work  capacity  due  to  mobility  of  the  terminals.  Dynamic 
bandwidth  changes  in  the  AN  backbone  create  very  unique 
challenges  for  IntServ  protocols.  RSVP  protocol  needs  to 
accommodate  bandwidth  fluctuations  as  well  as  an  in¬ 
creased  bit  error  rate  that  can  result  from  mobility.  Due  to 


the  constraints  of  encryption  in  the  AN,  monitoring  capa¬ 
bilities  such  as  Measurement  Based  Admission  Control 
(MB AC)  [5]  are  needed  at  the  ingress  and  egress  points  (in 
addition  to  provisioning  bandwidth)  to  detect  the  changes 
in  the  available  bandwidth  in  the  AN  links  in  near  real¬ 
time. 

The  Transmission  Path  may  not  be  Bi-Directional 

The  RSVP-AGG  or  the  RSVP  Proxy  technique  needs  to 
consider  that  we  cannot  always  assume  bi-directional 
transmission  on  the  entire  path.  This  could  occur  when  a 
node  is  being  jammed,  causing  it  to  transmit  in  one  direc¬ 
tion  to  a  neighboring  node  and  not  receive  from  the  same 
node  along  the  same  path.  Thus,  the  node  might  need  to 
form  a  uni-directional  link  to  some  other  neighbor  node  to 
complete  the  circuit.  This  would  create  an  issue  for  the  use 
of  RSVP-AGG  in  the  AN  since  RSVP-AGG  path  messag¬ 
es,  identical  to  RSVP,  are  generally  bi-directional.  Conse¬ 
quently,  the  application  of  any  type  of  RSVP,  including 
RSVP-AGG,  offers  a  great  challenge  that  is  further  ad¬ 
dressed  in  the  next  section. 

III.  THE  STUDY  DETAILS 

In  this  work,  we  focus  on  two  aspects  of  the  RSVP  study 
for  the  AN.  The  first  is  to  quantize  the  advantages  of  using 
RSVP-AGG  over  standard  RSVP.  The  second  is  to  quan¬ 
tize  the  effect  of  mobility  on  the  RSVP  protocol.  (RSVP 
was  originally  designed  for  wired  networks  and  its  perfor¬ 
mance  in  wireless  networks  with  packet  loss  can  cause 
degradation  in  the  protocol).  Advantages  of  statistical  mul¬ 
tiplexing  are  currently  under  study. 


Figure  1:  Red  Enclaves  Using  Black  AN  Core  for  Con¬ 
nectivity 

As  Figure  1  shows,  the  AN  core  (where  bandwidth  utiliza¬ 
tion  efficiency  is  needed),  is  envisioned  to  be  encrypted 
[using  Internet  Protocol  Security  (IPSec)  or  Type  1  High 
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Assurance  Internet  Protocol  Encryptor  (HAIPE)  encryp¬ 
tion].  Red  or  plain  text  enclaves  are  envisioned  to  use  the 
black  AN  core  for  internetworking  connectivity.  Secure 
RSVP-AGG  tunnels  are  established  between  pairs  of  red 
enclaves  over  the  black  core.  Conversion  between  RSVP 
flows  in  the  red  enclave  and  aggregated  tunnels  through 
the  black  AN  core  are  performed  by  an  edge  device  cur¬ 
rently  under  development. 


RSVP-AGG  over  IPSec 


Figure  2:  Implementation  of  RSVP-AGG  over  HAIPE 

An  implementation  using  HAIPE  encryption  can  have 
problems.  RSVP  is  based  on  end-to-end  signaling  and  the 
current  HAIPE  specification  does  not  allow  RSVP  signal¬ 
ing  to  be  passed  across  encryption  boundaries.  As  Figure  2 
shows,  individual  RSVP  flows  originating  in  a  red  enclave 
will  be  aggregated  by  the  (red)  edge  device  and  presented 
to  the  HAIPE  with  DSCP  classification  markings.  The  ag¬ 
gregated  flows  are  then  propagated  through  secure  HAIPE 
tunnels,  but  only  DiffServ  priorities  can  be  used  through 
the  black  core.  The  benefit  of  guaranteed  RSVP-AGG  be¬ 
tween  enclaves  over  the  black  core  is  lost  as  a  result  of  the 
HAIPE  encryption.  Even  so,  HAIPE  v3.1  will  allow  the 
mapping  of  Explicit  Congestion  Notification  (ECN)  bits 
between  the  red  and  black  sides  of  the  encryption.  These 
two  ECN  bits  can  be  used  as  a  component  of  a  Measure¬ 
ment-Based  Admission  Control  (MBAC)  mechanism  as 
they  will  provide  the  red  edge  device  an  indication  of  the 
level  of  black  core  network  congestion  [6].  Under  condi¬ 
tions  of  congestion,  an  MEPP -based  admission  control 
process  will  be  active  in  the  edge  device. 


AGG  tunnel  (to  accommodate  all  classes  of  service  and  all 
precedence  levels)  between  each  source  and  destination 
pair  of  red  enclaves.  As  the  results  in  the  next  section  ex¬ 
plain,  creating  a  single  tunnel  can  increase  the  AN  core 
throughput  efficiency  since  the  control  traffic  needed  to 
create  and  maintain  multiple  tunnels  is  significantly  more 
than  that  for  creating  and  maintaining  a  single,  aggregated 
tunnel.  Also,  the  single  tunnel  for  RSVP-AGG  is  generated 
just  once,  whereas  the  standard  RSVP  tunnels  are  created, 
maintained  for  the  life  of  each  session,  and  then  tom  down 
at  the  end  of  the  session. 

Aggregation  of  RSVP  at  the  AN  ingress  point  and  de¬ 
aggregation  at  the  egress  point  will  follow  RFC  4804  [3], 
as  mentioned  before.  Although  creating  a  single  tunnel  for 
aggregated  traffic  increases  the  AN  core  throughput  effi¬ 
ciency,  it  also  generates  a  set  of  challenges  regarding  ad¬ 
mission  control.  In  other  words,  the  aggregated  traffic 
needs  to  be  controlled  at  the  AN  ingress  point  using  some 
MEPP  policies  as  mentioned  above.  This,  however,  is 
beyond  the  scope  of  this  paper  and  the  reader  can  refer  to 
[5]  and  [6]  for  more  details  about  possible  admission  con¬ 
trol  policies  in  this  encrypted  environment. 

In  general,  RSVP-AGG  requires  that  the  return  path  for 
RESV  messages  be  identical  to  the  forward  path.  Howev¬ 
er,  if  a  bi-directional  link  is  not  available  in  the  AN  black 
core,  the  case  needs  to  be  looked  at  in  terms  of  route  dis¬ 
covery.  The  RSVP-AGG  packets  will  be  encrypted  over 
the  black  core  and  will  be  routed  according  to  the  route 
tables  in  the  black  routers,  which  are  based  on  Open 
Shortest  Path  First  (OSPF).  If  a  link  is  unidirectional  due 
to  jamming,  etc.,  the  routers  will  be  discovered  through 
this  link  in  one  direction,  and  the  reverse  path  can  be  tho¬ 
rough  different  hops  in  a  different  link.  In  other  words,  on 
one  hand.  Type  I  HAIPE  encryption  offers  a  challenge  in 
performing  call  admission  control  over  the  red  enclave 
with  limited  information  about  the  black  core,  while  on  the 
other  hand.  Type  1  HAIPE  encryption  offers  us  the  ability 
to  make  RSVP-AGG  (encrypted)  messages  pass  over  the 
black  core  even  with  uni-directional  links. 


The  current  state  of  the  art  for  handling  RSVP  between  red 
enclaves  over  an  encrypted  tactical  network  core  can  be 
found  in  some  of  the  WIN-T  QED  literature  [5]  where  the 
QED  proxies  RSVP  between  red  enclaves  using  MBAC. 
However,  the  QED  approach  does  not  use  RSVP-AGG. 
This  paper  makes  the  case  for  considering  RSVP-AGG 
instead  of  RSVP  in  order  to:  (1)  Reduce  control  signaling 
over  the  encrypted  core;  (2)  Be  more  tolerant  to  link  error; 
and  (3)  Define  a  reasonable  link  reliability  requirement  to 
maintain  RSVP  signaling  between  the  red  enclaves. 

The  need  for  BW  utilization  efficiency  that  is  driving  this 
study  leads  to  the  consideration  of  creating  a  single  RSVP- 


IV,  MODELING  AN  WITH  RSVP-AGG 

The  study  first  started  by  using  an  OPNET  model,  which 
had  some  limitations  since  OPNET  has  not  yet  imple¬ 
mented  the  RSVP-AGG  protocol.  Thus,  we  relied  on 
OPNET  for  multiple  runs  to  study  link  reliability  require¬ 
ments,  and  built  a  testbed  in  order  to  study  RSVP-AGG 
and  quantify  the  amount  of  B W  saving  over  RSVP  in  a  fair 
manner.  While  the  testbed  enabled  us  to  study  RSVP-AGG 
accurately,  OPNET  model  allowed  us  to  run  multiple  sce¬ 
narios  under  different  link  reliability  (bit  error  rate)  cases 
to  create  a  comprehensive  study. 
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Figure  3:  AN  Testbed  for  RSVP-AGG  Study 

The  AN  testbed,  shown  in  Figure  3,  represents  4  different 
AN  nodes  with  eipher  text  routers  (Ciseo  2800s).  Also 
shown  are  four  red  enelaves  (generating  a  mix  of  voiee, 
video  and  data  traffic)  with  red  routers  and  FIAIPE  surro¬ 
gates.  A  number  of  cases  were  run  to  study  RSVP  and 
RSVP-AGG.  One  case  where  two  red  enclaves  had  10  si¬ 
multaneous  RSVP  sessions  was  selected  to  compare 
RSVP-AGG  control  signaling  against  RSVP  control  sig¬ 
naling. 


Figure  4:  Control  Signaling  for  RSVP-AGG  vs.  RSVP 

Figure  4  shows  the  amount  of  measured  control  signaling 
in  bps  over  the  network  core  for  the  two  cases.  The  hori¬ 
zontal  axis  refers  to  a  token  number  which  is  a  heart  beat 
packet  sent  every  2  seconds  between  the  two  red  enclaves 


and  is  used  to  piggyback  the  single  RSVP-AGG  mainten¬ 
ance  packet.  One  can  see  how  the  RSVP-AGG  mainten¬ 
ance  traffic  fades  away  while  the  RSVP  maintenance  traf¬ 
fic  stays  around  800-1000  bps.  We  had  selected  a 
configuration  of  RSVP  that  generates  a  maintenance  pack¬ 
et  every  30  seconds.  More  frequent  maintenance  packets 
will  show  a  higher  gain  in  BW  savings. 

V.  BACKBONE  NETWORK  MOBILITY  ANALYSIS 

The  OPNET  model  used  to  study  link  reliability  represents 
a  simple  notional  AN  backbone  model  depicted  in  Figure 
5.  This  model  has  a  representation  of  the  AN  core  through 
three  aircrafts  (JSTARS,  AWACS,  and  Rivet-Joint).  It 
should  be  noted  the  AN  backbone  representation  of  Figure 
5  is  purely  notional  and  the  only  real  significance  to  the 
aircrafts  listed  in  the  scenario  is  that  those  are  all  examples 
of  widebody  aircraft  that  could  conceivably  someday  host 
AN  backbone  communications  systems.  There  is  no  im¬ 
plication  that  we  are  simulating  those  platforms  or  that  our 
results  are  in  anyway  indicative  of  the  performance  of  their 
current  communications  systems. 


Figure  5:  A  Notional  AN  Backbone  Model 


In  our  model,  a  representation  of  a  ground  terrestrial  net¬ 
work  is  used  to  inject  external  traffic  into  the  AN  core.  In 
this  study,  we  focused  on  the  1  Mbps  link  between  the 
JSTARS  and  Rivet  Joint  (shown  in  bold  red  in  the  figure) 
in  order  to  create  link  reliability  requirements. 

Note  that  the  RSVP-AGG  scenario  was  created  in  OPNET 
as  an  approximation  of  the  RSVP-AGG  protocol  which 
has  not  been  implemented  in  OPNET.  To  simulate  RSVP- 
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AGG,  we  created  a  single  RSVP  request  at  the  edge  that  is 
equivalent  to  a  bundle  of  sessions. 

Mobility  of  AN  backbone  nodes  can  cause  degradation  in 
BER.  (As  the  AN  backbone  nodes  get  further  away  from 
each  other,  the  SNR  of  interconnecting  radio  links  can  start 
decreasing,  resulting  in  degradation  in  the  BER.)  In  this 
section,  we  analyze  the  relationship  between  the  degrada¬ 
tion  in  BER  and  the  behavior  of  the  RSVP  mechanism. 

In  the  OPNET  model,  an  increase  in  the  link  BER  causes 
the  RSVP  module  to  crash  (the  reservation  terminates  in 
an  unexpected  manner).  As  BER  decreases,  reservation 
becomes  successful;  however,  it  terminates  (crashes)  after 
a  while  (i.e.,  it  cannot  be  kept  or  maintained).  Initial  results 
showed  that  the  AN  backbone  links  need  to  be  maintained 
at  a  BER  of  1 0'^  or  better  in  order  for  the  RSVP  protocol  to 
be  established  and  maintained  in  OPNET.  This  raised  the 
question:  Since  RSVP -AGG  is  anticipated  to  generate  less 
traffic  than  the  standard  RSVP,  can  this  translate  into  one 
being  able  to  establish  and  maintain  RSVP -AGG  under  a 
BER  worse  than  10'^?  To  answer  this,  we  relied  on 
OPNET  to  run  more  what-if  scenarios  to  compare  the  ef¬ 
fect  of  mobility  on  RSVP -AGG  versus  its  effect  on  the 
standard  RSVP  protocol. 

Here  we  present  link  reliability  results  from  three  different 
scenarios: 

■  Scenario  1  is  the  baseline  scenario  which  studies  the 
standard  RSVP  behavior  when  the  mobility  of  the 
backbone  causes  degradation  in  the  link  (JSTARS  to 
Rivet  Joint)  being  studied.  A  simulation  of  one  hour 
was  run  for  this  scenario. 

■  Scenario  2  replaces  the  standard  RSVP  with  RSVP- 
AGG  and  produces  comparable  results.  Two  cases  of 
this  simulation  were  run,  one  for  duration  of  one  hour 
and  the  other  lasting  a  day. 

■  Scenario  3  adds  additional  traffic  (from  AWACS  to 
Rivet  Joint,  light  red  line  in  Figure  3)  to  produce  re¬ 
sults  that  could  be  compared  to  the  other  scenarios 
when  the  link  under  study  (JSTARS  to  Rivet  Joint) 
shares  both  the  initial  traffic  as  well  as  the  additional 
traffic.  The  three  cases  for  the  first  two  scenarios  were 
repeated  under  this  scenario. 

The  results  of  these  simulations  are  presented  below.  Note 
that  the  results  below  are  dependent  on  random  number 
generation  from  OPNET.  While  using  a  common  random 
variable  approach  [7]  or  a  Monte  Carlo  processing  [8] 
could  yield  results  based  on  a  larger  sample,  we  found  that 
the  results  presented  below  are  sufficient  to  drive  home  the 
point  that  one  needs  a  certain  level  of  link  reliability  in 


order  to  maintain  RSVP  signaling  between  the  red  en¬ 
claves  over  the  AN  encrypted  core. 


Table  1:  Scenario  1  -  Baseline  RSVP 


Baseline  Scenario  -  RSVP  (1  Hr  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

0 

l.OE-04 

577  sec 

l.OE-05 

1054  sec 

l.OE-06 

Ihr-  Completed,  No  Crash 

0 

Ihr  -  Completed,  No  Crash 

Table  1  shows  the  results  obtained  from  the  baseline  sce¬ 
nario  and  lead  us  to  the  proposition  that  one  needs  to  main¬ 
tain  a  BER  of  10''’  or  better  in  order  to  make  sure  that 
RSVP  works  reliably.  These  results,  however,  used  the 
standard  RSVP  which  has  many  reservations  going  be¬ 
tween  the  JSTARS  and  the  Rivet  Joint  nodes. 


Table  2:  Scenario  2  -  RSVP-AGG  for  One  Hour 


RSVP-AGG  (1  Hr  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

1308  sec 

l.OE-04 

439  sec 

l.OE-05 

Ihr  -  Completed,  No  Crash 

l.OE-06 

Ihr  -  Completed,  No  Crash 

0 

Ihr  -  Completed,  No  Crash 

Table  2  shows  the  same  set  of  results  for  the  RSVP-AGG 
which  has  a  single  reservation.  One  can  see  that  one  hour 
of  simulation  was  completed  at  BER  of  10'^  (compared 
with  the  BER  of  10'^  for  the  previous  case).  This  can  be 
explained  simply  based  on  the  fact  that  there  is  less  control 
traffic  traversing  the  backbone  network  which  would  lead 
to  fewer  chances  for  a  control  packet  to  be  in  error  that 
causes  the  protocol  to  crash.  Note  from  the  table  that  con¬ 
trary  to  expectation,  the  simulation  time  for  BER  of  10'^ 
was  longer  than  that  for  1 0'"^.  This  could  be  just  a  coinci¬ 
dence,  perhaps  arising  from  a  random  error  pattern  that 
occurred  earlier  for  the  1 0'"^  BER  case,  affecting  the  proto¬ 
col  catastrophically. 

Table  3:  Scenario  2  -  RSVP-AGG  for  One  Day 
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RSVP-AGG  (1  Day  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

1757  sec 

l.OE-04 

720  sec 

l.OE-05 

Ihr  57  min  56  sec 

l.OE-06 

23hrs  28min  28  sec 

0 

24  hrs  -  Completed,  No  Crash 

The  results  in  Table  2  prompted  us  to  run  the  RSVP-AGG 
scenario  for  an  entire  day,  with  the  results  as  presented  in 
Table  3.  This  shows  that  at  BER  of  10'^,  the  protocol 
crashed  in  a  little  less  than  2  hours,  while  at  BER  of  1 0’^, 
the  protocol  almost  completed  the  entire  day.  This  empha¬ 
sizes  the  initial  recommendation  of  keeping  the  BER  at  the 
AN  backbone  links  at  1 0“'^  or  better. 

All  of  the  above  results  were  conducted  when  the  traffic 
was  flowing  between  only  two  nodes  (JSTARS  and  Rivet_ 
Joint),  with  the  focus  on  the  link  between  them.  For  Scena¬ 
rio  3,  we  added  additional  traffic  flow  from  the  AWACS 
to  the  Rivet  Joint  node,  in  order  to  study  the  effect  of 
mixed  traffic  on  the  performance  of  standard  RSVP  and 
RSVP-AGG  protocols.  The  above  three  cases  were  simu¬ 
lated  for  the  Scenario  3  and  the  results  are  presented  in 
Tables  4,  5  and  6. 


Table  4:  Scenario  3  -  Baseline  RSVP 


Baseline  Scenario  -  RSVP  (1  Hr  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

604  sec 

l.OE-04 

695  sec 

l.OE-05 

2406  sec 

l.OE-06 

Ihr  -  Completed,  No  Crash 

0 

Ihr  -  Completed,  No  Crash 

The  results  in  Table  4  are  similar  to  those  in  Table  1.  From 
the  table,  one  can  see  that  for  duration  of  1  hour  of  simula¬ 
tion  time,  as  before,  one  should  maintain  a  BER  of  1 0'^  or 
better  in  order  to  complete  the  scenario  with  the  standard 
RSVP.  The  slightly  longer  simulation  times  (compared  to 
Table  1)  before  the  crash  for  the  cases  of  BER  of  10'^,  10'"^ 
and  10'^  are  likely  from  random  error  patterns  occurring 
somewhat  later. 

Table  5:  Scenario  3  -  RSVP-AGG  for  One  Hour 


RSVP-AGG  (1  Hr  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

625  sec 

l.OE-04 

586  sec 

l.OE-05 

1776  sec 

l.OE-06 

Ihr  -  Completed,  No  Crash 

0 

Ihr  -  Completed,  No  Crash 

Table  5  repeats  the  same  mixed  traffic  while  using  RSVP- 
AGG  for  one  hour  simulation  between  JSTARS  and  Ri- 
vet  Joint  nodes.  One  can  draw  a  conclusion  similar  to  that 
from  Table  4  that  one  needs  to  maintain  a  BER  of  10'^  or 
better  in  order  to  complete  the  scenario  simulation. 


Table  6:  Scenario  3  -  RSVP-AGG  for  One  Day 


RSVP-AGG  (1  Day  Simulation) 

BER 

Simulation  Time  for  RSVP  Crash 

0.1 

0 

0.01 

0 

l.OE-03 

625  sec 

l.OE-04 

586  sec 

l.OE-05 

1776  sec 

l.OE-06 

24hr  -  Completed,  No  Crash 

0 

24hr  -  Completed,  No  Crash 

Table  6  shows  the  last  set  of  results  where  we  use  RSVP- 
AGG  with  a  mix  of  traffic  and  run  the  simulation  for  an 
entire  day.  One  can  see  that  similar  to  the  conclusion  from 
Table  5,  one  needs  to  maintain  a  BER  of  10''^  or  better  in 
order  to  complete  the  scenario  for  the  entire  day. 

VI,  FUTURE  WORK 

This  work  is  currently  being  extended  to  study  the 
advantages  of  statistieal  multiplexing  when  all  traffie 
is  aggregated  over  a  single  tunnel  instead  of  over  mul¬ 
tiple  tunnels.  As  the  tactical  edge  performs  Admission 
Control  (AC),  it  can  admit  more  sessions  in  an  aggregated 
tunnel  than  in  separate  tunnels  (whereas  the  summation  of 
the  BW  of  the  separate  tunnels  is  equal  to  the  aggregated 
tunnel  BW  and  the  QoS  requirements  in  the  two  cases  are 
the  same).  Note  that  the  reservation  request  would  be 
based  not  on  the  peak  rate  but  the  average  rate.  At  a  specif¬ 
ic  moment,  some  sessions  in  the  aggregated  tunnel  would 
peak,  i.e.,  use  more  bandwidth  than  the  reserved,  while 
other  sessions  might  be  using  less  than  the  reserved  BW. 
Statistical  multiplexing  of  the  aggregated  session  can 
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create  higher  efficiency  in  using  the  AN  backbone  re¬ 
sources. 

VII.  SUMMARY 

We  ran  a  number  of  simulations  of  the  performance  of  an 
airborne  network  using  the  OPNET  model  and  a  HW 
testbed,  and  showed  the  following: 

1  -  RSVP-AGG  has  distinct  advantages  over  the  stan¬ 
dard  RSVP  protocol  in  increasing  the  network’s 
throughput.  Reduced  protocol  overhead  and  the 
advantage  of  statistical  multiplexing  offered  by 
(“longer-lasting”)  RSVP-AGG  tunnels  between 
AN  enclaves  result  in  significant  bandwidth- 
utilization  efficiency  compared  to  individual 
(“short-term”)  RSVP  tunnels  per  flow. 

RSVP-AGG  bandwidth  guarantees  cannot  be  pro¬ 
vided  in  a  black  core  implementation  with  HAIPE 
enclave  encryption.  However,  a  measurement  and 
MEPP-based  admission  control  process  can  be 
implemented  that  exploits  ECN  bits  mapped  be¬ 
tween  the  black  core  network  and  red  enclaves 
(per  HAIPE  v3.1  specifications). 

2-  To  maintain  the  RSVP-AGG  protocol  successful¬ 
ly,  we  must  ensure  that  the  BER  over  the  AN 
backbone  links  does  not  exceed  1 0'^  (based  on  the 
OPNET  simulation  results,  pending  further  inves¬ 
tigations  on  the  AN’s  behavior  for  transmission  er¬ 
rors). 
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